I enjoy talking to people during events. Discussions can go in many directions. And recently I spoke about how to start contributing to FOSS projects.
How I started
My first contribution was an update of the official installation guide for Debian on Amiga. Pure documentation, no code involved.
My first source code change came two years later. A few lines of C which were accepted after some changes.
How you can start
At first, check which projects you are using. And then go through a simple checklist:
- Is there something you would like to see changed?
- Is it translated into your native language (never mind would you use it or not)?
- Is there any documentation for it?
- Is documentation useful/up to date?
- How many bugs does the project have?
Non-code contributions are the best ones
Nowadays, everyone can submit code to any project — all those LLM/AI tools can generate code for you in seconds. Will anyone review and accept it is another thing.
But going in the other direction is a much better way…
Documentation
Check how well the project is documented. Maybe something is hard to understand due to language/grammar used — not everyone speaks/writes in the same way.
Maybe documentation is completely missing. Or describes only some parts of a project. Or is outdated.
When I got hired for my second job, my first task was to get familiar with the software I would be developing by reading its documentation. I crossed out most of screenshots and several paragraphs because they were two months old and the app got renamed in the meantime.
So check docs and send corrections. Make it up to date and complete.
Translations
Not everyone speaks English. Even when many people think that everyone should.
Software projects can be translated into other languages. Check is your project of choice available in your language. Regardless of whether you would you use that translation or not.
Maybe previous translator moved to other tasks and new version needs some new strings in your native language? Or no one translated it before?
Check translation guidelines from some larger projects like GNOME or KDE — they may have dictionaries ready to use so you do not have to reinvent new name for ‘a directory’ (folder, catalogue, drawer etc.).
Bug triaging
Triage is the process of quick prioritisation in time-critical situations. It Came to software from the medical field, where it was used to categorise the wounded into “can wait”, “needs urgent care”, “hopeless” and “deceased”.
In software development this phrase is used to quickly review bugs. Which ones are trivial, which are worthless etc.
So go to your project’s bug tracker and take a look.
Maybe someone reported a bug with short note but without reproduction steps. If you know how to reproduce the bug: add such steps and confirm that you can reproduce it too. The developer will not have to wonder how to replicate the bug on their system (and believe me: it can be tricky).
Maybe project has some bugs marked with kind of “good first issue” label. Small changes needed to make it done but no one has time to deal with them so they leave them for new contributors.
UI hints
Sometimes developers design the UI for their apps to fit their use. Which may be in violation of HIG (Human Interface Guidelines) of the desktop project it was written for.
Open a bug, point to UI mistakes, propose how it should be done (even by doing quick edits of screenshot). You do not need to know how to code to be able to do it.
Or you think that UI is overloaded and can be changed to a more readable one. Do some mockups, discuss with project.
Offer help in your areas of expertise
None of things above match your background? Fine. Ask project where they need help.
- Is their website awful or not-existent and you are a web developer?
- Do you know how to automate CI using GitHub Actions, Forgejo runners, or another solution they can use?
- Do the project’s build artifacts need testing? Users might be willing, but there is no one to coordinate them.
It may sound strange but such needs exist. Been there, done that. Some entries more than once.
Final words
There are many non-code ways to contribute to FOSS projects. I have only listed a small subset. Which ones you choose is entirely up to you.